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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport System (ITS). 

The present document is part 3 of a multi-part deliverable covering Intelligent Transport Systems (ITS); Vehicular 
Communications; Basic Set of Applications, as identified below: 

Parti: "Functional Requirements"; 

Part 2: "Specifications of Cooperative Awareness Basic Service"; 

Part 3: "Specifications of Decentralized Environmental Notification Basic Service" ; 

Part 4: "Operational Requirements". 



Introduction 



ITS use cases are distributed over multiple ITS stations. Co-operating ITS stations are interacting to provide a large 
diversity of customer services that satisfy different types of functional and operational requirements. 

ETSI TC ITS has defined a Basic Set of Applications (BSA) [i.8] that can be deployed within a three-year time frame 
after the completion of their standardization. In this BSA, the Road Hazard Warning (RHW) application is composed of 
multiple use cases. ETSI TC ITS defines the decentralized environmental notification (DEN) basic service that supports 
the various RHW use cases. The specification of this basic service is the purpose of the present document. 

The RHW application is an active road safety application that is distributed among vehicles ITS station and roadside 
ITS stations. The application execution is achieved through direct V2V / I2V communications. 

Furthermore, this application broadcasts useful information that is related to road traffic conditions. Consequently, 
roadside ITS stations may collect the broadcasted information from vehicle ITS stations, process the information and 
forward the information to a central ITS station in order to improve the traffic efficiency and traffic management. In this 
case, the application execution can be achieved through V2V/I2V and/or other communications as defined in [6]. 
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Scope 



The present document provides the specification of the DEN basic service, which mainly supports the RHW 
apphcation. 

More specifically, the present document specifies the semantics of the Decentralized Environmental Notification 
Message (DENM) and the DENM handling. 

A DENM transmission is triggered by a cooperative RHW use case to provide information about a specific driving 
environment event or traffic event to other ITS stations. The ITS station that receives the DENM is able to provide 
appropriate HMI information to the end user, who makes use of these information or takes actions in its driving and 
travelling. 

The concept of the DEN basic service is derived from the functional requirements of BSA as defined in [i.4] and 
operational requirements of BSA as defined in [i.5]. 

Detailed specifications of the RHW use cases are out of scope of the present document. 

The present document is based on DENM specifications defined in [i.l] and [i.2]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] SAE J2735: "Dedicated Short Range Communications (DSRC) message set dictionary". 

NOTE: Available at: http://www.itsware.net/itsschemas/DSRC/DSRC-03-00-36/ . 

[2] Mobile.Info WG Automotive (March 2006): "TPEG TEC Application Specification Vl.O". 

[3] ETSI EN 302 665: "Intelligent Transport Systems (ITS); Communications Architecture". 

[4] ITU-T Recommendation X.691/ISO/IEC 8825-2: "Information technology - ASN.l encoding 

rules: Specification of Packed Encoding Rules (PER)". 

NOTE: Available at: http://www.itu.int/ITU-T/studvgroups/coml7/languages/X.69 l-0207.pdf . 

[5] Mobile.Info WG Automotive (March 2006): "TPEG-Automotive Protocol Location Container 

TAP-LOCVl.O". 

[6] ETSI TS 102 636-3: "Intelligent Transport Systems (ITS); Vehicular Communications; 

GeoNetworking; Part 3: Network architecture". 
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2.2 Informative references 



The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] Car2Car Communication Consortium (August 2007): "Car2Car Communication Consortium 

Manifesto", Version 1.1. 

NOTE: http://www.car-2-car.org . 

[i.2] Car2Car Communication Consortium: "Message description: Decentrahzed Environmental 

Notification Message", Version 1.0. 

[i.3] ETSI TR 102 863: "Intelligent Transport System (ITS); Vehicular Communications; Basic Set of 

Applications; Local Dynamic Map (LDM); Rationale for and guidance on standardization". 

[i.4] ETSI TS 102 637-1: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set 

of Applications; Part 1: Functional Requirements". 

[i.5] ETSI TS 102 637-4: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic set 

of applications; Part 4: Operational Requirements". 

[i.6] ETSI TS 102 637-2: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set 

of Applications; Part 2: Specification of Cooperative Awareness Basic Service". 

[i.7] ETSI TS 102 636-4-1: "Intelligent Transport System (ITS); Vehicular communications; 

GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and 
point- to -multipoint communications; Subpart 1: Media independent functionalities". 

[i.8] ETSI TR 102 638: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of 

Applications; Definitions". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purpose of the present document, the terms and definitions given in EN 302 665 [3] and the following apply: 

application support: subset of facilities, providing support elements for applications 

basic set of applications: group of applications, supported by the vehicular communication system 

NOTE: The basic set of applications can be deployed at a targeted time (day 1) after completion of their standards 
with the objective to serve societal and business objectives of private and public road transport 
stakeholders. The BSA is defined in [i.8]. 

communication support: subset of facilities, providing support for communications 

DEN basic service: set of facilities and components to support RHW use cases, DENM management and DENM 
dissemination 

DENM: ITS facility layer message providing RHW related information 

destination area: geographical area for DENM dissemination 

NOTE: The destination area is defined and specified by the ITS networking and transport layer. 
event: road hazard situation, a driving environment situation, or a traffic condition situation 

NOTE: An event potentially has an impact on the road safety, the traffic efficiency and/or the driving conditions. 
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facilities: functionalities, services or data provided by the facilities layer 



NOTE: These functionalities, services and data are gathered in the ITS facilities layer, which contains some 
generic application elements (middleware), presentation and session layers of the OSI (Open System 
Interconnection) reference model. 

information support: sub set of facilities, providing support for data management 

ITS application: system that defines and implements an ITS service for the users of the system 

ITS use cases: procedure of executing an ITS application in a particular situation with a specific purpose 

LDM: local georeferenced database containing a V2X-relevant image of the real world 

NOTE: Applications can retrieve the data from the LDM by means of the LDM Management [i.3]. 
originator ITS station: In the context of the present document, the ITS station that generates and transmits the DENM 
reference position: In the context of the present document, a geographical position that represents the event position 

NOTE: The reference position is included in the DENM as a data frame. 

reliability: In the context of the present document, the probability that a detected event is truly existent 

relevance area: geographical area, one or several road section, or a traffic direction within which ITS stations are 
concerned by the event 

V2I, I2V: direct vehicle to roadside infrastructure communication using a wireless local area network 

V2V: direct vehicle(s) to vehicle(s) communication using a wireless local area network 

NOTE: Other networks can be used for use case development. The selection of the optimal network in term of 

cost-efficiency will be dynamically achieved, in the future, according to the local availability of networks, 
their respective costs and performances. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in EN 302 665 [3] and the following apply: 

ASN. 1 Abstract Syntax Notation One 

BER Basic Encoding Rules 

BSA Basic Set of Applications 

CAM Cooperative Aware Message 

CAN Controller Area Network 

DE Data Element 

DEN Decentralized Environmental Notification 

DENM DEN Message 

DP Data Frame 

DSRC Dedicated Short Range Communications 

HMI Human Machine Interface 

ITS Intelligent Transport System 

LDM Local Dynamic Map 

OSI Open System Interconnection 

PDU Protocol Data Unit 

PER Packed Encoding Rules 

RHW Road Hazard Warning 

S AE Society of Automotive Engineers 

TEC Traffic Event Compact 

TPEG Transport Protocol Experts Group 

UTC Coordinated Universal Time 

V2I Vehicle-to-Infrastructure 

V2V Vehicle-to-Vehicle 

V2X V2V and/or V2I 
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Road hazard warning application general overview 



4.1 Application overview 



Decentralized Environmental Notification Messages (DENMs) are mainly used by the Cooperative Road Hazard 
Warning (RHW) application in order to alert road users of the detected events. The RHW application is an event-based 
application composed of multiple use cases. The general processing procedure of a RHW use case is as follows: 

• Upon detection of an event that corresponds to a RHW use case, the ITS station immediately broadcasts a 
DENM to other ITS stations located inside a geographical area and which are concerned by the event. 

• The transmission of a DENM is repeated with a certain frequency. 

• This DENM broadcasting persists as long as the event is present. 

NOTE 1 : According to the type of the detected event, the DENM broadcasting can be realized by the same ITS 

station, temporarily realized by one or several ITS station(s), or relayed by one or several ITS station(s). 

• The termination of the DENM broadcasting is either automatically achieved once the event disappears after a 
predefined expiry time, or by an ITS station that generates a special DENM to inform that the event has 
disappeared. 

• ITS stations, which receive the DENMs, process the information and decide to present appropriate warnings or 
information to users, as long as the information in the DENM is relevant for the ITS station. 

NOTE 2: A general use case procedure and DENM transmission data flow is provided in the annex C. 

As defined in [i.8], the RHW application includes thirteen use cases. It is expected that further use cases will be added 
in the future. 

Table 1 provides examples of the triggering and termination conditions of sending DENM. 
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Table 1 : Triggering and termination conditions of DENIU! sending 



Use case 


Triggering condition 


Terminating condition 


Emergency electronic brake 
light 


Hard breaking of a vehicle 


Automatic after the expiry time 


Wrong way driving warning 


Detection of a wrong way driving by the 
vehicle being in wrong driving direction 


Vehicle being in the wrong way 
has left the road section 


Stationary vehicle - 
accident 


e-Call triggering 


Vehicle involved in the accident 
is removed from the road 


Stationary vehicle - vehicle 
problem 


Detection of a vehicle breakdown or 
stationary vehicle with activated warnings 


Vehicle is removed from or has 
left the road 


Traffic condition warning 


Traffic jam detection 


End of traffic jam 


Signal violation warning 


Detection of a vehicle being violating a 
signal 


Signal violation corrected by 
the vehicle 


Road-work warning 


Signalled by a fix or moving roadside ITS 
station 


End of the roadwork 


Collision risk warning 


Detection of a turning collision risk by a 
roadside ITS station 


Elimination of the collision risk 


Detection of a crossing collision risk by a 
roadside ITS station 


Elimination of the collision risk 


Detection of a merging collision risk by a 
roadside ITS station 


Elimination of the collision risk 


Hazardous location 


Detection of a hazardous location 


Automatic after the expiry time 


Precipitation 


Detection of a heavy rain or snow by a 
vehicle (activation of the windscreen 
wrappers) 


Detection of the end of the 
heavy rain or snow situation 


road adhesion 


Detection of a slippery road condition (ESP 
activation) 


Detection of the end of the 
slippery road condition 


Visibility 


Detection of a low visibility condition 
(activation of some lights or antifog) 


Detection of the end of the low 
visibility condition 


Wind 


Detection of a strong wind condition 
(stability control of the vehicle) 


Detection of the end of the 
strong wind condition 



4.2 Concept of DEN basic service 



Given the similarity of the different RHW use cases, a set of facilities and components have been defined and grouped 
into the DEN basic service. In particular, the DEN management domain facility is defined as the main facility to 
generate, update and terminate the transmission of DENM. Facilities and components belonging to the DEN basic 
service are presented in figure 1 . 

NOTE: The common and domain facilities are defined in [i.4]. 
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Figure 1 : DEN basic service components 

A DENM provides information related to an event that has a potential impact on road safety. Furthermore, a DENM can 
be used for traffic efficiency use cases. In such a situation, a use case may require the dissemination of a DENM over a 
long distance or to a central ITS station, such as for vehicle rerouting or traffic management. 

In general, an event is characterized by an event type, a geographical position or an area, the detection time and a 
duration. These attributes may change over space and over time. A DENM, which concerns the same event, may be 
issued by multiple originator ITS stations at different positions and persists even after the originator ITS stations have 
passed by. Therefore, the detected event can be independent from the originator ITS stations. Furthermore, the 
reliability of the provided information related to the same event may vary at different originator ITS stations, depending 
on the detection capability of that ITS station. 



DEN basic service 



5.1 Functional components 

As presented in figure 1 , the main functional components that belong to the DEN basic service are the DEN 
management facility, the LDM and the RHW application. Other facilities may be required to exchange information with 
these DEN basic service components. Detailed information exchange differs from use case to use case 

5.1.1 DEN management 

The DEN management provides the following functionalities: 

• DENM format management 

The DEN management holds information related to the DENM formats and semantic of DENM, a protocol 
version number is attached to each version of DENM format. Therefore, the DENM management also 
manages the update of DENM protocol. 
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Generation of DENM 



The DEN management provides interfaces to the corresponding RHW apphcation and other facihties in order 
to collect the needed information for DENM construction and updates. 

When the originator ITS station detects the event evolution, the DEN management constructs new DENM 
including the updated information. A data version number is assigned to DENM to indicate the event 
evolution. 

• Management of DENM and information dispatching in the ITS station 

In case multiple DENMs are received by an ITS station, the DEN management provides functionalities to 
manage DENMs. This includes, not exhaustively: 

the deletion of DENMs with outdated information; 

the invalidation of outdated information; 

the dispatching of event information included in the DENM to the LDM, to the ITS application layer and 
to other facilities for further processing; 

the correlation of information from multiply received DENMs, in order to judge whether different 
DENMs sent from the same originator ITS station or from different originating ITS stations are 
concerned by the same event. 

NOTE: This functionality should be supported by the LDM as defined in [i.3]. 

• Delivery of the relevant communication parameters to the ITS networking and transport layer for DENM 
dissemination 

5.1 .2 Local Dynamic Map (LDM) 

The LDM is updated based on received DENMs. 

NOTE: The detailed specification of LDM [i.3] is out of scope of the present document. 

5.1.3 RHW application 

A RHW application is a component that initiates the broadcasting of a DENM and triggers the termination of DENM 
dissemination concerning the same event. 

NOTE 1 : The detailed specifications of the RHW application are out of the scope of the present document. 

A non-exhaustive list of information that the RHW application should provide to the facilities layer for DENM 
construction and DEN management includes: 

• Event type: the type of the detected event. An identifier is assigned to each specific event as cause code and/or 
sub cause code. 

• Event position: the position of the detected event. In case the event covers an area, the event position may be 
described by a reference position or a geographical description of the event area. 

NOTE 2: The detailed specifications of the event position is use case specific, therefore is out of the scope of the 
present document. Examples of the reference position of events are illustrated in annex D. 

• Location referencing information for the event position. 

• Detection time: time at which the event is detected. 

• Event expiry time: time at which the event is expected to be terminated. In case that the originator ITS station 
is not able to detect the event expiry time, an estimated expiry time may be provided by the RHW application 
at the originator ITS station. The expiry time can be updated, terminated or dynamically extended if an event 
evolution is detected. 
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• Relevance area: a geographical area or road sections in which ITS stations are concerned by the event. 

• DENM transmission frequency: the nominal time interval between two consecutive DENMs issued by the 
same ITS station. 

5.2 DENM dissemination 
5.2.1 Dissemination requirements 

A DENM shall be disseminated to as many ITS stations as possible located within the relevance area. This includes ITS 
stations entering the destination area until the expiry time and ITS stations that have no connectivity to the originator 
ITS station when the DENM was issued. A list of DENM dissemination requirements are defined by the RHW 
application. 

• DENM transmission frequency: the time interval between two consecutive DENMs sent out by the same ITS 
station. 

• Required DENM transmission latency: the time interval between the time when a DENM is delivered by the 
facilities layer to the ITS networking and transport layer at the originator ITS station and the time when the 
DENM is delivered by the ITS networking and transport layer to the facilities layer of the receiving ITS 
station. 

• DENM priority: DENM priority is defined by the RHW application and assigned as specified in [i.5]. 

NOTE 1 : The dissemination requirements may be combined into one traffic class that represents the QoS 
requirement of a DENM. The concept of the traffic class is defined in [i.5]. 

• Destination area: geographical area that DENMs are required to be disseminated. 

NOTE 2: The destination area description is as specified in [i.7]. In case the relevance area and the destination area 
is not identical, the DEN management should be able to convert the relevance area to the destination area 
before delivering to the ITS networking and transport layer. 

The DENM dissemination shall rely on the functionalities of the ITS networking and transport layer, in particular on 
GeoNetworking functionalities as defined in [6] . 

5.3 Ternnination of tine event 

The termination of the event can be indicated in two ways: 

• A cancellation DENM is sent by the originator ITS station when the event termination is detected. The 
cancellation message is regarded as a DENM with a special data version. 

• A negation DENM is sent by one or several third party ITS stations that have received DENM earlier. When 
such third party ITS stations detect that the event does not exist anymore, it generates a DENM to negate the 
event. A negation flag is included in the DENM. The third party ITS stations that initiate the event negation 
shall be an authorized ITS station. 

Once cancellation or negation DENM are verified to be trustworthy by the receiving ITS stations. All previously 
received DENMs concerning the same event shall be cancelled from the DEN management. Information included in 
those DENMs should be set as invalid inside the receiving ITS stations. 

Once a cancellation or negation DENM is transmitted by an ITS station, it shall be repeated for a certain duration 
defined by the RHW application. 
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5.4 



General confidence constraints 



A DENM provides a qualitative description of a detected event. Special constraints may apply to some attributes 
provided within the event description. DENMs include information about the reliability level to be associated to the 
event (isNegation, reliability). 

Position confidence level constraints is use case specific. Detailed specifications are out of scope of the present 
document. 



5.5 General security constraints 

Security-related information is not included in DENM. 

NOTE: The detailed specifications of DENM security mechanism will be defined by the WG5 of ETSI ITS TC. 

5.6 General priority constraints 

The DENM priority is defined by the RHW use case as specified in [i.5]. 

Priority information is transmitted by lower layers and is therefore not included in the DENM. 



6.1 



Message format specification 



General structure 



A DENM PDU is composed of a common ITS PDU header and a DENM. The header indues basic information 
including the protocol version, the message type (CAM or DENM) and the generation time of the message. A DENM 
consists of three fixed order parts: the management container, the situation container and the location container. The 
general structure of a DENM is illustrated in figure 2. Each container is composed of a sequence of data elements (DE) 
and data frames (DP). A DE and a DP is either optional or mandatory. If not specified as optional in the present 
document, a DE or DP is considered as mandatory. 

NOTE: A DP is composed of a fixed sequence of at least two DEs. 
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Figure 2: General structure of the DENM 
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6.1 .1 DENM management container 



The management container holds management information of a DENM. Specific DEs are included in the management 
container to indicate the reliability level, the event evolution and the event termination. The reliability level is expressed 
by the DE reliability, the event evolution is indicated by the data version, and the event termination can be indicated by 
a special data version number or a negation flag DE. 

Information included in the management container shall allow ITS station to distinguish different originator ITS stations 
and different events without ambiguity. 

6.1 .2 DENM situation container 

The situation container includes information that describes the detected event as well as its potential impact to the road 
safety and traffic flow. The situation container is composed of the following DEs and DFs: 

• Traffic flow effect: this DE provides traffic flow status caused by the event. That is, whether the event has 
caused a traffic jam, dense traffic, or does not have impact on the traffic flow. 

• The information may require specific jam detection means at the originator ITS station. The DE is optional. 

• Cause code: this DE provides a description of the direct cause for the event. 

• Sub cause code: this DE is used to provide more detailed information for the direct cause. For example, 
extreme weather conditions being the direct cause, strong wind, precipitation or strong snow are specified in 
the sub cause. 

• The sub cause DE can be set to unknown if the originator ITS station does not have the required detection 
capability. In this case, this DE is set to "0". 

• Direct cause DE and sub cause DE are combined into the situation DF. 

• Linked cause: this DF provides description of another event that are related to or being the cause to the direct 
cause. For example, an accident is detected caused by the low road adhesion situation. Accident is defined as 
the direct cause, while low road adhesion is assigned as linked clause. 

• Linked cause is described by the situation DF. This DF is optional. The originator ITS station should 
determine whether to add a linked cause in DENM, depending on its detection capability, 

• Severity: this DE provides a severity level of the event to the overall traffic. Various events are classified into 
four severity levels, with 1 for relatively low safety impact and 4 for high safety critically events. Detailed 
specifications of severity shall be as specified in [2] . 

• Basic event characteristics: This DF is used to provide basic characteristics of the event in order to facilitate 
the collision risk estimation and/or better understanding of the event natures at the receiving ITS station. These 
characteristics specify: 

event mobility: whether the detected event is static or in mobility; 

cause type: whether the detected event is caused by an ITS station in danger, or is a location or a road 
section that cause the danger; 

relevant: whether the detected event is physically relevant to the received ITS stations (accident) or 
describes difficult driving conditions (strong wind on the road); 

time criticality: whether the detected event is time critical and requires high attention from the driver 
(hard brake vehicle) or provide some traffic information (traffic jam). 
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• Others: supplementary information related to the event may be included in the situation container if such 
information is known and available at the originator ITS station. These supplementary information can be 
different depending on the detected event. For example, for the slow vehicle, further information for the 
vehicle type, vehicle size and vehicle speed limit can be provided. As another example of the traffic condition 
warning, supplementary information can be needed to indicate the restrictive vehicle type, if the traffic 
condition is only dedicated to a specific vehicle type. 

These supplementary information is provided as optional data within the situation container. Vehicle common 
parameters and profile parameters as defined in [1] can be used. 

Considering the RHW use cases, assigned cause code and sub cause code is presented in the table 2. If not specified 
within table 6.1, specifications on direct cause and sub cause shall be as specified in [2]. 

Table 2: Cause description and cause code assignment for RIHW use case 



Use case 


Direct 
cause code 


Direct cause 


Sub cause 
code 


Sub cause 


Emergency electronic brake 
lights 


101 


Dangerous Driving 


1 


Hard brake vehicle 


Wrong way driving warning 


* 


Wrong way driving 







Signal violation warning 


102 


Intersection violation 


1 


Stop sign violation 


2 


Traffic light violation 


3 


Turning regulation violation 


Stationary vehicle - accident 


* 


Accident 







Stationary vehicle - vehicle 
problem 


103 


Vehicle problems 


1 


Break down vehicle 


2 


Vehicle speed reduced with 
safety lights on. 


Slow vehicle warning 


* 


Slow vehicle 







Traffic condition warning 


* 


Traffic jam 







Roadwork warning 


* 


Road work 







Collision risk warning 


104 


Intersection collision 


1 


Left turn collision risk 


2 


Right turn collision risk 


3 


Crossing collision risk 


4 


IVIerging collision risk 


Hazardous location 


105 


Hazardous location 


1 


Dangerous curve 


2 


Obstacle on the road 


Precipitation 


* 


Precipitation 


* 


Heavy rain 


* 


Heavy snow 


Wind 


* 


Extreme weather 
condition 







Road adhesion 


* 


Slippery Road 


* 


Low road adhesion 


* 


Black ice 


Visibility 




Visibility reduced 


* 


Bad visibility due to frost 


* 


Bad visibility due to storm 


Emergency vehicle 
approaching 




Rescue on the way 




Emergency vehicle 



6.1 .3 DENM location container 

The location container consists mainly of three DFs: the event position, the location referencing and the relevance area. 



6.1.3.1 



Event position 



The event position describes the geographical position of the detected event. The event position can be represented as a 
geographical position or as an event area. 

• The exact event position: When the event is located at a specific geographical position (e.g. the current 

position of a vehicle ITS station in accident event), the geographical coordinates of this position are provided 
and augmented with speed and moving direction. 
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• Event reference position: When the event covers a geographical area or cannot be precisely detected by the 
originator ITS station, an event reference position DF can be defined and used as the event position. For 
example, the reference position could be the border point position of a road hazard area, which is closest to the 
relevance area, or the current position of the originator ITS station of the DENM. Detailed definition of the 
event reference position is use case specific. In case the detected event is in mobility, further information such 
as speed, moving direction are included as optional information in the event reference position. 

The event reference position and the exact event position are described in a DF RefPosition. 

• Event area: In another way to describe the event position when the event covers an area, the geometrical 
description of the event area can be provided in a event area DF. The event area DF may be coded with 
combination of one or several RefPosition DFs or other DEs, such as length, road segment identifier etc. 

NOTE: Detailed specifications of the event area DF may be as specified in [5]. 

6.1 .3.2 Relevance area 

The relevance area describes a geometrical area, a road topology area and/or a specific traffic direction that the ITS 
stations located within such area are concerned by the event. The relevance area indicates the minimum area where the 
DENMs should be disseminated and the transmission direction of the DENMs along the road traffic. DENM according 
to the selected traffic class shall be disseminated to as many ITS stations as possible located in or entering into the 
relevance area. Receiving ITS station makes use of the relevance information to realize the relevance check and to 
manage the information related to the event. The relevance area DF is included in DENM. 

NOTE 1 : The relevance area is defined by the RHW use case, a sample text description of the relevance area for the 
RHW use cases are provided in the annex D of the present document. 

According to the use case requirements, the relevance area DF can be described in several ways: 

• Geographical area: The relevance area DF is described by a geometric shape. In this case, the DF is combined 
by one or several geographical point DFs or other DEs such as distance. For example, for a road accident on a 
motorway, the relevance area of the DENM related to the vehicle accident is a certain distance from the 
accident position. 

• Road topology: The relevance area DF is described by one or several road segments identifiers. For example, 
for roadwork, the relevance area of the DENM related to the roadwork is one or multiple road sections that are 
influenced by the roadwork. 

• Dissemination traffic direction: The relevance area DF is described by a traffic direction along which DENM 
is disseminated. For example, for a traffic jam on a motorway, the relevance area of the DENM related to the 
traffic jam is the upstream direction of the traffic jam. 

According to [i.7], the destination area can be defined by geometrical shapes of different size. Three shapes are 
currently defined: 

• circular shape; 

• rectangular shape; 

• elliptical shape. 

The relevance area is not necessarily identical with the destination area used at the ITS networking and transport layer 
as defined in [i.7]. However, the destination area shall cover the relevance area. 

In case the relevance area description is different from the destination area description, the DEN management shall 
convert the relevance area to the destination area as specified in [i.7]. 

NOTE 2: Detailed specifications of the relevance area DF are use case specific and out of the scope of the present 
document. 

Examples for the relationship and the difference among the event position, the relevance area and the destination area 
are provided in figures 3 and 4. 
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Destination area 
Reference position 



Relevance area 



Road hazard 




I 



I ) 
I / 



Figure 3: Example of the event reference position, 
the relevance area and the destination area, highway scenario 



Destination area 
Reference position 



Relevance area 




6.1.3.3 



Figure 4: Example of the event reference position, 
the relevance area and the destination area, intersection scenario 



Location referencing 



This DF provides location referencing information of the event position. Multiple location referencing mechanisms may 
be used depending on the use case requirements. One location referencing mechanism that can be used for RHW use 
cases is the trace location referencing. 

The trace location referencing provides a list of waypoint positions that lead towards the event position. One trace 
contains several waypoints that forms an itinerary approaching to the event position. Multiple traces can be included in 
this location referencing for an event, if ITS stations can encounter the detected event from different road sections or 
from different traffic flows. 

Trace location referencing is defined and provided by the originator ITS station. 

The selection of the optimal location referencing mechanism to be used as well as the detailed specifications of the 
location referencing are out of the scope of the present document. 



6.2 



Detailed DENM format 



The following clauses define the DENMs DE and DF. 



6.2.1 



Format definition of DENM 



The present clause shows the DENM format in a semantic representation. Data presentation shall be as determined in 

clause 6.2.4. 
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The entries referring to "Byte Position" in the table 5 are therefore arbitrary and Hsted to aid the understanding of the 
semantic representation only. The real position of the element in the data-stream is defined by the ASN.l definition in 
clauses 6.2.3, 6.2.4 and 6.2.5. 

NOTE: The ASN. 1 presentation of DEs and DFs is presented in annex B of the present document. 

6.2.2 Data presentation of DENM 

The DENM format is presented in ASN.l. Unahgned packed encoding rules (PER) as defined in ISO/IEC 8825-2 [4] 
shall be used for encoding and decoding. 

NOTE: A general description of ASN. 1 PER is presented in annex A of the present document. 

The DENM shall be sent in the sequence defined in the clauses 6.2.4, 6.2.5 and 6.2.6. Figure 5 provides the order of bits 
and bytes in the DENM. 



Byte -1 


Byte 2 Byte 3 


Byte 4 








Byte n 










Bit # 7 Bit # 6 Bit # 5 Bit # 4 Bit # 3 Bit # 2 Bit # 1 Bit # O 



Figure 5: Bits and bytes in DENIV! 

6.2.3 Content of DENM 

For illustration purposes, table 3 provides an example summary of the content and the format of a DENM. 
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Table 3: Content and format of a DENM 



Container 


Block 

# 


Name 


Byte PC 
First 


(Sition 
Last 


Type 


Unit 


O/IW 


Description 


ITS PDU 
header 


1 


Protocol Version 


1 


1 


Integer 




M 


Indicates the 
current version of 
the protocol being 
used at the 
management 
container level 


2 


IVIessage ID 


2 


2 


Integer 




M 


IVIessage type 
identifier associated 
to DENM 


3 


Generation Time 


3 


8 


Integer 


UTC 

millisec 


M 


Timestamp when 
the DENM is 
generated, 
milliseconds 
elapsed since 
midnight January 
1st, 1970 UTC 


IVIanagement 


4 

Action 

ID : 


Originator ID 


9 


12 


Integer 




M 


ITS station identifier 


Sequence Number 


13 


14 


Integer 




M 


Sequence number 
provided by the 
originator when an 
event is detected 
for the first time. 


5 


Data version 


15 


15 


Integer 




M 


Data version 
indicating an 
update of the event 
evolution. Set to 
255 for cancellation 
message 


6 


Expiry Time 


16 


21 


Integer 


UTC 
millisec 


M 


Timestamp of event 
expiry, milliseconds 
elapsed since 
midnight January 
1st, 1970 UTC 


7 


Frequency 


21 


21 


Integer 







Transmission 
frequency of DENM 
as defined by the 
originator ITS 
station. 


8 


Reliability 


22 


22 


Integer 




M 


Probability for the 
event information to 
be true. Bit 7 to bit 
1 of the byte 22 


9 


IsNegation 


22 


22 


Boolean 




M 


Bit of byte 22 
when "1" negates 
the existence of the 
event 


Situation 


10 


CauseCode 


23 


23 


Integer 




M 


Identifier of the 
event direct cause 
as specified in 
table 1 


10 


SubCauseCode 


24 


24 


Integer 




M 


Sub cause as 
provided in table 1 


11 


Severity 


25 


25 


Integer 




M 


Severity value of 
the event 



£75/ 



21 



ETSI TS 102 637-3 VI. 1.1 (2010-09) 



Container 


Block 

# 


Name 


Byte Position 


Type 


Unit 


0/IVI 


Description 


Location 
container 


12 


RefPosition_Situation 
Latitude 


26 


29 




1/10 

micro 

degree 


M 


Latitude of the 
event reference 
position 


13 


RefPosition_Situation 
Longitude 


30 


33 


Integer 


1/10 

micro 

degree 


M 


Longitude of the 
event reference 
position 


14 


RefPosition Situation 
Altitude 


34 


35 


Integer 


1/10 
meter 


M 


Altitude of the event 
reference position 


15 


Accuracy 


36 


39 


String 




M 


Event position 
accuracy 


16 


Other DEs and DFs 
for the relevance 
area and the location 
referencing 


40 


n 






M 


This block is 
defined and 
specified by the 
RHW application 
with variable sizes 



6.2.4 DENM format 

The ASN.l representation of the DENM is represented in figure 6. 



-- ASNl START 












DENM-PDU-Descriptions { 












itu-t (0) identified-organization (4) etsi (0) itsDomain (5) 

} 

DEFINITIONS AUTOMATIC TAGS ::= 


wgl (1) ts (102637) denm (3) version2 (2) 












BEGIN 












DenmPdu ::= SEQUENCE { 












header 


ItsPduHeader, 










denm 
} 


DecentrahzedEnvironmentalNotificationMessage 








DecentralizedEnvironmentalNotificationMessage ::= SEQUENCE { 








management 


DecentrahzedSituationManagement 












— container with DEN 


management and version control 


situation 


DecentrahzedSituation 


— container with event 


description 


, incl. type, severity 


location 


DecentrahzedSituationLocation 

— container with event location, 
with more detailed location 


location referencing 
description and the 


} 




relevance area 
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DecentralizedSituationManagement::= SEQUENCE { 

— unique identifier about an event from one originator ITS station, combination of node ID and a sequence 

number 

actionID ActionID, — 6 byte 

— version of the DENM indicating updates from the same originator ITS station; value of 255 is used for the 

cancellation message sent from the originator ITS station 

data Version DataVersion, — 1 byte 

— time when the DENM is deleted from the DEN management and the information related to the event is set as 

invalid.. If it is not provided, it indicates that the expiry time is unkown by the originator ITS station 

expiryTime TimeStamp OPTIONAL, — 6 byte 

frequency INTEGER (0.. 255) OPTIONAL, -units in O.IHz 

— probability of the detected event to be true, varies from to 100, with maximum value as fidl reliability 
reliability INTEGER(0..100), - 7 bits 

— negates the existence of an event at the event position by a third part ITS station that have received DENMs 

previously. 

isNegation BOOLEAN -- 1 bit 



— event description derived from [2] 
DecentralizedSituation::= SEQUENCE { 

— traffic status near the event position, defined based on [2], TPEG table tecOOl 
trafficFlowEffect TrafficFlowEffect OPTIONAL, - 1 byte. 

— event direct cause and sub cause description as defined in tab6.1 and in [2] 
situation Situation, 

— linked cause if information is available. 

linkedCause Situation OPTIONAL, - 2 Byte, 

— severity value of the event, defined in [2], TPEG table tec003 
severity Severity, — 7 byte 

— characteristics of the event 

eventCharact SEQUENCE -- EventCharact 1 byte 



{ 



-- event mobility description, set to TRUE if the event is in mobility 
eventmobility BOOLEAN, 

— whether the event is caused by the originator ITS station 
causeType ENUMERATED { itsStation, geographicalRegion } 
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— whether the event is physicalling relevant to the receiving ITS station 
relevance ENUMERATED {physicallyRelevant, difficultDrivingConditions }, 

— whether the event is time critical road safety event, set to TRUE if it is the case. 
timeCriticality BOOLEAN, 

— more characteristics may be added. 



} OPTIONAL, 

vehicleCommonParameters VehicleCommonParameters OPTIONAL, 
profile ProfileParameters OPTIONAL 



DecentralizedSituationLocation::= SEQUENCE { 
-- description of the event position. 
eventPosition CHOICE { 

— the geographical position of the event reference position 
eventPositionCurrentDefinition EventPosition, 

}, 

— description of the relevance area for the DENM dissemination 

— location referencing of the event position 
locationRef CHOICE { 

— consequence position of the trace location referencing mechanism 
trace TraceLocData, 

— more location referencing mechanism to be added 



}, 



EventPosition ::= SEQUENCE { 

refPosition ReferencePosition, 

— event speed, either equal to or different from the vehicle speed 
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eventSpeed 



Speed 



OPTIONAL 



ActionID ::= SEQUENCE 
stationID 
sequenceNo 



StationID, 
SequenceNo 



a 4 byte value 
a 2 byte value 



Elevation ::= INTEGER (-10000.. 16767215) 



multiples of 0.1 m 



ItsPduHeader ::= SEQUENCE { 

— protocolVersion fixed to 

protocol Version INTEGER(0..255), 

-- message type ID associated to CAM = 0, DENM=1 

messagelD INTEGER(0..255), 

— milliseconds elapsed since midnight January 1st, 1970 UTC 
generationTime TimeStamp 



Latitude ::= SEQUENCE 
hemisphere 
degree 



ENUMERATED { north (0), south (1) }, 

INTEGER (0..900000000) -- multiples of 0.1 microdegree 



Longitude ::= SEQUENCE { 

hemisphere ENUMERATED { east (0), west (1) }, 

degree INTEGER (0. . 1 800000000) -- multiples of 0. 1 microdegree 



ReferencePosition ::= SEQUENCE { 
longitude Longitude, 

latitude Latitude, 

elevation Elevation, 

heading Direction 



OPTIONAL, 



—present if rnobileltsStation flag is TRUE 
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streetName 


StreetName 


OPTIONAL, 






positionConfidence 


Confidence 


OPTIONAL, 


—present if jnobileltsStation flag 


is TRUE 


elevationConfidence 


Confidence 


OPTIONAL, 


—present if mobileltsStation flag 


is TRUE 


roadSegmentID RoadSegmentID 

} 


OPTIONAL 






SequenceNo ::=INTEGER (0..65535) 


— increased by 1 each time a new event is detected by the 
station. 


same ITS 


DataVersion ::= INTEGER {firstVersion(0),secondVersion(l),cancellation(255) } (0..255) 




TrafficFlowEffect ::= INTEGER(0..7) 


— values as specified in 
unknown. 


[2], set to 1 when the traffic flow 


effect is 


Situation ::= SEQUENCE { 










cause 


CauseCode, 


- 1 byte 






subCause 
} 


SubCauseCode 


; -- 1 byte 






— 1 to 100 indicates causecode defined within [2] 






— 101 to 255 indicates causecode without being defined by [2] 






CauseCode::=INTEGER{ 










reserved 


(0), 








dangerousDriving 


(101), 








intersection Violation 


(102), 








vehicleProblem 


(103), 








intersectionCollision 


(104), 








hazardousLocation 


(105) 








} (0..255) 










SubCauseCode ::= INTEGER {unknown(O)} (0..255) 






Severity ::= ENUMERATED 

f 


-- 1 byte 








1 

informative 


(1), 
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— Text example: <Attention, there is a dangerous obstruction due to fog> 
obstacles (2), —danger level 1 

— Text example: <Attention, there a danger due to fog> 
danger (3), —danger level 2 

— Text example: <Attention, highest danger due to fog> 
highestDanger (4) —danger level 3 



Speed ::= INTEGER (-32765.32765) -- multiples of 0.01 m/s 

StationID ::= INTEGER(0.. 4294967295) 

TraceLocData ::= SEQUENCE { 

—3 bits, identifier of the trace 
tracelD INTEGER(0 .. 7), 

—5 bits, number of waypoint positions included in the trace 
waypoints SEQUENCE (SIZE(0..31)) OF Waypoint 



TimeStamp ::= INTEGER (0.. 281474976710655) -- units of milliseconds, 6 byte 

Waypoint ::=SEQUENCE{ 

— waypoint positions included in the trace. 
ptLat Latitude, —a 4 bytes value 

ptLong Longitude, —a 4 bytes value 

ptAIt Elevation, 



— common and profile dependent parameter definitions follow 

ProfileParameters ::= CHOICE { 

basicVehicle BasicVehicle, 

emergency Vehicle EmergencyVehicle, 

pubUcTransportVehicle Public Transport Vehicle, 
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} 

VehicleCommonParameters : 


= SEQUENCE { 


vehicleType 


VehicleType, 


stationLength 


StationLength, 


stationLengthConfidence 


Confidence OPTIONAL, 


stationWidth 


StationWidth, 


station WidthConfidence 


Confidence OPTIONAL, 


vehicleSpeed 


VehicleSpeed, 


vehicleSpeedConfidence 


Confidence, 


longAcceleration 


LongAcceleration, 


longAccelerationConfidence Confidence, 


accelerationControl 


AccelerationControl, 


yawRate 


YawRate, 


yawRateConfidence 


Confidence, 


exteriorLights 


ExteriorLights, 


turnAdvice 


TurnAdvice OPTIONAL, 


distanceToStopLine 


DistanceToStopLine OPTIONAL, 


occupancy 


Occupancy OPTIONAL, 


doorOpen 


DoorOpen OPTIONAL, 


posConfidenceEllipse 


PosConfidenceEllipse, 


curvature 


Curvature, 


curvatureChange 


CurvatureChange OPTIONAL, 


curvatureConfidence 


Confidence, 


crashStatus 


CrashStatus OPTIONAL, 


headingConfidence 


Confidence, 


dangerousGoods 
1 


DangerousGoods OPTIONAL, 


1 

BasicVehicle ::= SEQUENCE { 

} 
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EmergencyVehicle ::= SEQUENCE { 


lightBarlnUse 


LightBarlnUse OPTIONAL, 


sirenelnUse 


SirenelnUse OPTIONAL, 


emergencyResponseType 


EmergencyResponseType, 


1 

PublicTransport Vehicle ::= SEQUENCE { 


public VehicleType 


Public VehicleType, 


pTLineDescription 


PTLineDescription OPTIONAL, 


scheduleDeviation 


ScheduleDeviation OPTIONAL, 


trafficLightPriority 

1 


TrafficLightPriority OPTIONAL, 


1 

AccelerationControl ::= BIT STRING { 


brakePedal (0), 




throttlePedal(l), 




cruiseControl (2), 




ace (3), 




limiter (4), 




brakeAssist (5) 
} 




AmbientAirTemperature ::= Temperature 


Confidence ::= INTEGER (0. 


.15) 


CourseOfJourney ::= IA5String(SIZE(0..32)) 


CrashStatus ::= BOOLEAN 




Curvature ::= INTEGER (-32765. .32765) 
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CurvatureChange ::= INTEGER (-1023.. 1023) 

DataReference ::= IA5String(SIZE(1..128)) 

DangerousGoods ::= INTEGER (0..8191) 

Dimension ::= INTEGER (0.. 16383) 

Direction ::= INTEGER {north(O), east(7200), south(14400), west(21600)} (0..28799) 

Distance ::= INTEGER (0..65535) -- multiples of 1.0m 

DistanceToStopLine ::= Distance 

DoorOpen ::= BIT STRING { 
driver (0), 

passenger (1), — any passenger door 
maintenance (2), — hood, other access to engine, or similar 
luggage (3) 



EmergencyResponseType ::= ENUMERATED { 
none (0), 

staticSafeguard (1), — e.g. at accident spot 
movingSafeguard (2), — e.g. convoy or abnormal load 
rightOfWay (3), — claiming right of way 



ExteriorLights ::= BIT STRING 
lowBeamHeadlightsOn (0), 
highBeamHeadlightsOn (1), 
leftTumSignalOn (2), 
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rightTurnSignalOn (3), 
automaticLightControlOn (4), 
daytimeRunningLightsOn (5), 
fogLightOn (6), 

parkingLightsOn (7) 



LightBarlnUse ::= SimpleSystemState 



LineRef ::= IA5String(SIZE(0..32)) 



LongAcceleration ::= INTEGER (-2000..2000) -- multiples of 0.01 m/s'^2 



Occupancy ::= INTEGER (0..255) 



PosConfidenceEllipse ::= SEQUENCE { 
semiMajorConfidence Confidence, 

semiMinorConfidence Confidence, 

semiMajorOrientation Direction 



confidence of the ellipse's major semi-axes 
confidence of the ellipse's minor semi-axes 



Priority ::= INTEGER(0..7) 

PTLineDescription ::= SEQUENCE { 

courseOfJourney CourseOfJourney, 

lineRef LineRef, 

routeRef RouteRef 



Public VehicleType ::= INTEGER(0..255) 



RoadSegmentID ::= INTEGER (0.. 99999999) 



RouteRef ::= IA5String(SIZE(0..32)) 
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ScheduleDeviation ::= INTEGER (-900. .3600) — seconds, positiv delay; negative ahead of schedule 

SimpleSystemState ::= ENUMERATED { 
unavailable (0), — not equipped or out of order 

disabled (1), — switched off by user or due to driving situation, e.g. ACC below minimum speed 
enabled (2), — switched on but no action, e.g. ESP in normal operation, limiter below limit speed 
engaged (3) — switched on and in action, e.g. light bar flashing, limiter limiting speed 



SirenelnUse ::= SimpleSystemState 

StationLength ::= Dimension 

Station Width ::= Dimension 

StreetName ::= IA5String(SIZE(1..32)) 

Temperature ::= INTEGER (-40..215) 

TrafficLightPriority ::= Priority 

TurnAdvice ::= SEQUENCE { 
direction TurnDirection, 
distance Distance 



TurnDirection ::= BIT STRING 
uTurn (0), 
sharpRight (1), 
right (2), 
slightRight (3), 
straight (4), 
slightLeft (5), 
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left (6), 
sharpLeft (7) 



VehicleSpeed ::= Speed 

VehicleType ::= INTEGER (0..255) 

WiperSystemFront ::= ENUMERATED 
idle (0), 

interval (1), 
normal (2), 
fast (3), 

washerActive (4) 



YawRate ::= SEQUENCE { 
yawDirection ENUMERATED { left (0), right (1) 
yawRate Value INTEGER (0.. 32765) 



multiples of O.Oldeg/s 



END 



ASNISTOP 



Figure 6: ASN.1 notation of the DENIV! 
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Annex A (informative): 
Packed encoding rule 



Packed encoding rules (PER) are ASN.l encoding rules for producing a compact transfer syntax for data structures 
described in ASN.l. It provides a more compact encoding based on the data type to generate much more compact 
representations than Basic Encoding Rules (BER). PER specifications are defined by ITU-T 
(ITU-T Recommendation X.691) and adopted by ISO standards (ISO/IEC 8825-2) [4]. 

In BER encoding rules, a common form of encoding commonly known as Tag-Length-Value is used. Each item is 
encoded as a tag, indicating what type it is, a length indicating the size of the object, and a value, which contains the 
actual contents of the object. 

PER uses additional information from the ASN.l specification to represent the data units using the minimum number of 
bits. However, the compactness requires that the decoder knows the complete abstract syntax of the data structure to be 
decoded. 

PER only generates tags when they are needed to prevent ambiguity. Lengths are only generated by PER when the size 
of an object can vary. Even then, PER tries to represent the lengths in the most compact form possible. 

There are two variations of packed encoding rules: unaligned and aligned. With the unaligned encoding, the bits are 
packed with no regard for octet (byte) boundaries. With aligned encoding, certain types of data structures are aligned on 
octet boundaries, which may result in some number of wasted bits. Unaligned encoding uses the least number of bits by 
allowing values such as Booleans and small integers to be compacted together in one byte, but presumably at some cost 
in processing time. 

The presence of optional elements in a sequence is indicated by a list of single bit flags placed at the start of a sequence 
if the bit is set, then the option is present. 
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Annex B (normative): 

ASN.1 presentation for data elements and data frames 

A DENM carries the following data elements (DE) and data frames (DF). 



B.1 DE_protocol Version 



Purpose 


Version identifier for the underlying protocol specification. 

It shall be used to select the appropriate protocol decoder at the receiver ITS station. 


Notes 


This DE enables separate versioning of this message type. For the present standard, 
this protocol version is set to 0. 



B.2 DE_messagelD 



Purpose 


Message type identifier assigned to the DENM. 


Notes 


This DE should be harmonized with other V2X message identifier definition. For 
DENM, the messageld is set to 1 . 



B.3 DE_generationTime 



Purpose 



Time at which the DENM was generated. It denotes the time difference in milliseconds 
since a well-defined start time - here milliseconds since 1 .1 .1970 00:00:00.000. 



Notes 



This DE should be harmonized with the general V2X message timestamp definition. 



B.4 DF actionID 



Purpose 


Identifier generated each time an ITS station detects an event at a specific position for 
the first time. 

The actionID value is composed of an ITS station Identifier and a sequence number. 
The sequence number is increased by 1 each time a new event is detected by the ITS 
station. 

The actionID differs from all actionlDs generated by other ITS stations and from the 
actionlDs generated by the same ITS station for other detected events while the 
original DENM is valid. It is used to allow receiving ITS stations to process information 
for DENMs that are multiply received. 


Notes 


For the event covering an area, a moving vehicle ITS station may detect the 
persistence of the same event at different positions. The actionID should be maintained 
by the originator ITS station and remain the same if this originator ITS generates 
multiple DENMs regarding the same event. 

The station ID should be harmonized with general station ID definition. A temporary 
station ID (e.g. pseudonyms) can be used. 
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B.5 DE dataVersion 



Purpose 


Data version that indicates an update of information related to an event described by a 
previous DENIVI from the same originator ITS station. 

For the 1^' DENM generated by the originator ITS station, this DE is set to 0. With each 
update it is increased by one. The maximum value of 255 indicates a cancellation, 
i.e. the node indicates that the event described with the same actionID does not exist 
anymore. 

This dataVersion number is in correspondence with the evolution of the event, (e.g. the 
position of black ice changes). The updating rate (i.e. the rate of dataVersion value 
changes) depends on the dynamism of the detected event itself and is determined by 
the originator ITS station. However, between two updates, the DENM might be 
repeatedly sent to other ITS stations. 


Notes 


The actionID shall remain unchanged while dataVersion is increased. However, if the 
data version is used up from to 254, then a new DENM with a new actionID should 
be generated with a data version set to 0. 



B.6 DE_expiryTime 



Purpose 


Time when the information becomes invalid and the DENM should be deleted from the 
DEN management. 

The expiry time is set by the originator ITS station. Therefore it is only an estimation of 
how long the event may persist. It implies the duration over which the DENM should be 
kept at the application layer of the receiving ITS station and the DENM dissemination 
be maintained in the relevance area, until the expiryTime or until a cancellation or a 
negation DENM is received. 

This DE is optional. When it is not provided by the originator ITS station, it indicates 
that the expiry time is "unknown". 


Notes 


In order to keep the DENM alive in the relevance area during this time, it can be either 
managed at the originator ITS station by sending periodically DENMs or at a receiving 
ITS station by forwarding or delaying the DENMs to other ITS stations entering into the 
relevance area. For the latter situation, packet-centric store-and-forward at the ITS 
networking and transport layer or information centric forwarding at the ITS facility layer 
can be used. 

This DE is optional. In case the expiry time of the event cannot be estimated at the 
originator ITS station, either this expiry time is not provided, either a default value can 
be set by the originator ITS station. Expiry time can be renewed by the originator ITS 
station or an authorized ITS station relaying the DENM, if the pre-set expiry time has 
reached to 70 % of its limit and the event persistence is detected. 

The ActionID shall be remained unchanged when the expiry time is renewed. However, 
the data version should be increased by one when the expiry time is renewed. 



B.7 DE_frequency 



Purpose 


Sending frequency of the DENM as defined by the originator ITS station. 
This DE informs receiving ITS stations the intended transmission frequency of DENM. 
It can be used in situation when the originator ITS station has lost the capability of 
sending DENMs (e.g. accident vehicle battery down) and the DENM is relayed by a 
third part ITS station (e.g. roadside ITS station). This third part ITS station shall be an 
authorized ITS station. 


Notes 


This DE is optional, the originator ITS station should determines whether to add this 
DE. 
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B.8 DE_reliability 



Purpose 



The probability of the event to be truly existent at the event position. An initial value is 
set by the originating ITS station in accordance to the used sensor data and detection 
means. 



Notes 



is set to indicate the unknown probability and 100 to indicate maximum reliability. 



B.9 DEJsNegation 



Purpose 


Flag DE that indicates the event described by a previously received DENM from other 
ITS stations does not exist. 

DENIVIs with this flag set to be true are generated after the event was announced by 
another ITS station previously. It is used to announce a third part termination. 


Notes 


When it is set to true, information described in the DENM is not detected by the 
originator ITS station. 

As example a vehicle ITS station negates a traffic jam that was announced previously 
by another ITS station when it passes the corresponding road section with normal 
speed. 



B.10 DE trafficfloweffect 



Purpose 


Traffic flow situation where the event is detected. 


Notes 


This DE definition shall be as specified in [2]. When the traffic flow effect is unknown, it 
is set to 1 . 



B.11 DF situation 



Purpose 


Description for the event type, including direct cause and sub cause. 

A causeCode may be combined with a subcauseCode that further describes the event. 


Notes 


The definition of cause and subCause shall be as specified in [2] and in table 1 of the 
present document. 



B.12 DF linkedCause 



Purpose 


The description of the linked causes related to the event if such linked event is 

detected at the originator ITS station. 

This DF is optional. The definition is the same as the situation DF. 


Notes 


The originator ITS station that has the capacity to detect the linked cause should 

determine whether to add this DF. 

The cause definition shall be as specified in [2] and in table 1 of the present document. 



£75/ 



37 



ETSI TS 102 637-3 V1.1.1 (2010-09) 



B.13 DE_severity 








Purpose 


Severity level of the event to the road safety. 






Notes 


The severity level is set to 1 if the detected event has low impact on the road safety, 
is set to 4 if the detected event is a safety critical event. 


it 












B.14 DF_eventCharacteristics 








Purpose 


Basic characteristics of the detected events. 
This DF is optional. 






Notes 


IVlore event characteristics may be defined and added. 





B.15 DF eventPosition 



Purpose 


Geographical position of the event position. 

The position of the event is determined by the RHW application at the originator ITS 
station. If the position is the position of a vehicle ITS position, then the reference position 
of the vehicle is given as specified in [1]. Optionally, when the event is moving, a speed 
can be given. 


Notes 


The event position may be described as an event area DF, by a geographical area 
(i.e. geometric shape) or by other DEs, e.g. the road segment identifier, in case the 
originator ITS station is able to detect the event area. 

The event area DF may be as specified in [5]. 



B.16 DF ref Position 



Purpose 


The reference position of the event, when the originator ITS station is a vehicle ITS 
station. The reference position is the provided by the vehicle reference position as 
specified in [1]. 


Notes 





B.17 DEJongitude 



Purpose 


Absolute geographical longitude in a WGS84 co-ordinate system, range limited to 0,84° 
approx 50 km at 50° Latitude. 
Granularity 0,1 microdegree. 


Notes 


The direction flag is used to save the bandwidth for aligned PER. 
Reference SAEJ2735 Compliant to SAE J2735 DE_Longitude in [1]. 
Reference TPEG Longitude in TPEG-LOC in 10 micro-degrees units in [2]. 
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B.18 DE_atitude 






Purpose 


Absolute geographical latitude In a WGS84 coordinate system. 
Granularity 0,1 microdegree. 






Notes 


The direction flag is used to save the bandwidth for aligned PER. 
Reference SAEJ2735 Compliant to SAE J2735 DE_Latitude in [1]. 
Reference 7PEG Latitude in TPEG-LOC in 10 micro-degrees units in [2]. 










B.19 DE_eevation 






Purpose 


Altitude in a WGS84 co-ordinate system. 
Granularity 0,1 m. 






Notes 


Reference SAE J2735 Compliant to SAE J2735 DE Elevation in [1 ]. 










B.20 DE_heading 






Purpose 


Orientation of the detected event, if the detected event has an orientation. 
Granularity 0,01 25 degrees from North. 






Notes 


This DE is optional and only present if the originator ITS station is able to detect the 
direction of the event. 










B.21 DE positionConfidence 






Purpose 


Provides the position confidence level of the 2D positioning. 






Notes 


Detailed specifications can be as defined in [1]. 










B.22 DE_e evationConfidence 






Purpose 


Provides the confidence level of the elevation. 






Notes 


Detailed specifications can be as defined in [11. 










B.23 DE_eventSpeed 






Purpose 


Speed of the detected event when the detected event is mobile. 
Any speed. Negative values imply the vehicle is moving in reverse. 
Granularity 0,01 m/s. 






Notes 


This DE is optional and only present if the originator ITS station is able to detect the 
speed of the detected event. 
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B.24 DF traceLocData 



Purpose 


Trace location referencing tliat describes a set of consecutive waypoint positions 
leading to the event position. 

ITS stations located near to or inside this trace positions can be concerned by the 
event. IVIultiple traces can be defined in case multiple road sections or traffic flows are 
leading to the event position. 

For each trace, multiple waypoint positions are provided to describe the trace. 
Definition of waypoints is specific to the RHW use case. 


Notes 
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Annex C (informative): 

General use case procedure and data flow 

RHW use cases follow a common general procedure and data flow: 

Road hazard detection 

Use case triggering/terminating 

DENM construction and transmission 

Dissemination and updating 

DENM reception and handling 

HMI warning 

The general data flow is illustrated in figure C.l. The originator ITS station detects, generates and transmits a DENM 
via the ITS network. At the receiver ITS station, the DENM is processed and the information is checked. If necessary, a 
warning is provided to the user. 
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Figure C.I : General inter layer dataflow for road hazard warning application and DENM 
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C.1 Road hazard detection 



The RHW is based on the detection of the corresponding event. The RHW application is triggered only when the ITS 
station is capable of detecting the corresponding event with a minimum reliability. For a vehicle ITS station, the 
detection capabilities may require access to vehicle electronic functions, e.g. to engine/power train, ESP, speed control 
system, yaw rate, steering wheel angle or in vehicle sensor data such as tire pressure sensor, temperature, another via 
in-vehicle communication network, e.g. CAN. For a roadside ITS station, specific sensors may be required for the 
detection. Furthermore, sensor data fusion may be required to achieve the detection goal and improve the detection 
reliability. 

However, in some situation, a RHW application can decide not to trigger a DENM even if an event is detected. This can 
be the case when the ITS station has already received DENMs concerning the same event from other ITS stations. 

Regardless of the types and performance of the detection means, basic attributes related to the event including the event 
type, detection time, event position should always be provided to the RHW application. 



C.2 Use case triggering and termination 

In this procedure, RHW application corresponding to the detected event is triggered at the originator ITS station. The 
main sub-procedure of this procedure include: 



C.2.1 Application data provision 



A RHW application determines and provides information either from the detection means or according to predefined 
rules to the facilities layer for the construction of a DENM. For information related to the event that cannot be detected 
or provided by the detection means, e.g. the duration of the situation, specific algorithm can be used in order to define 
an estimated value. 

All event related information as defined in clause 5.1.3 is provided to the DEN management domain facility for the 
construction of the DENM. 

This sub-procedure is realized by the RHW application under the support of relevant facilities and detection means. 

C.2. 2 Communication requirement definitions 

The RHW application defines and provides the relevance area information to the DEN management. The DEN 
management further converts the relevance area to the destination area as specified by the ITS networking and transport 
layer. Then the facilities layer provides the destination area to the ITS networking and transport layer as dissemination 
requirements. Furthermore, the ITS facilities layer provides others dissemination requirement such as DENM 
transmission frequency and DENM transmission latency to the ITS networking and transport layer. 

This sub-procedure is realized by the DEN Management under the support of the RHW application and communication 
support facilities. 

C.2.3 DENIVI construction 

This sub-procedure constructs and encodes a DENM and provides it to the ITS networking and transport layer as 
payload. If an event evolution is detected by the originator ITS station, updated information is added to a new DENM 
with a new data version number by the originator ITS station. The actionID remains unchanged. 

This sub-procedure is realized by the DEN management and communication support facilities. 
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C.2.4 Termination 



A RWH application should stop sending and forwarding the DENM when the event terminates. In a situation where the 
termination cannot be detected or predicted by the originator ITS station when generating a DENM, the DENM 
dissemination is terminated in one of the following means: 

• a DENM cancellation message is sent from the originator ITS station if the event termination in detected. The 
cancellation message is constructed as a specific version (dataversion set to 255) of DENMs; 

• a DENM negation message is sent from a third party ITS station in order to indicate the event termination 
related to a previously received DENM. A negation message carries a isNegation flag set to true. 



C.3 Dissemination and updating 

The transmission of DENM happens when: 

• the scheduled time of sending DENM is reached based on the required transmission frequency; 

• an evolution of the event is detected and an updated DENM is constructed by the DEN management; 

• a cancellation message is constructed; 

• the expiry time is not achieved. 

The communication system forwards a DENM to the required destination area. Forwarding can be done either directly 
at ITS networking and transport layer, or at the ITS facilities layer. ITS Facilities layer forwarding is realized by the 
information-centric forwarding. It can be used to keep only updated DENMs alive within the destination area. 
Information-centric forwarding also maintains the updated DENMs in the forwarding buffer by deleting duplicate 
received DENMs and outdated DENMs. 

DENM forwarding may follow the following rules: 

• The ITS networking and transport layer dissemination is used to disseminate the DENMs to the required 
destination area. The ITS facilities layer does not participate to this forwarding. 

• When a receiving ITS station of a DENM is located in the destination area, the DENM is forwarded to the ITS 
facilities layer. The ITS facilities layer performs the information-centric forwarding in order to keep the 
DENM alive during the whole event duration within the relevance area. 

For multiply received DENMs with the same action ID, the DENMs including more recent data version 
and higher reliability are kept for forwarding. 

For multiply received DENMs with different action IDs, the DEN management checks with the support 
of the LDM and other facilities in order to correlate the information related to the event. This correlation 
allows the ITS station to judge whether the previously received DENMs concern the same event. If yes, 
DENMs that carries the most updated event information and/or higher reliability are selected for 
forwarding. 

Selected DENMs based on the above two rules are maintained in the forwarding buffer at the ITS 
facilities layer as long the information is still valid and as long as the ITS station is still located inside or 
within the communication range of the relevance area. 

If new ITS stations are detected to enter the relevance area (e.g. known by receiving a CAM from a new 
ITS station), the ITS facilities layer at the ITS station that performs the information-centric forwarding 
can decide to relay the DENM to this new ITS stations. 
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C.4 DENM handling 



At the originator ITS station, a DENM should include a reliability value that describes the probability of the information 
included in DENM being true. 

At the receiver ITS station, upon reception of a DENM, the DEN management can decide whether the information in 
the DENM is redundant to other previously received DENMs. Redundancy may refer to the same DENM that has been 
repetitively sent from the originator ITS station, or a different DENM that describes the same event, either transmitted 
by the same originator ITS station, or by other ITS stations. Redundant and outdated DENM will be discarded by the 
DEN management. Afterwards, valid DENM information is delivered to other facilities and to the ITS application layer. 

The RHW application at the receiving ITS station interacts with the LDM and other facilities in order to check the 
relevance of the event with regards to itself. The receiving ITS station furthermore estimates the risk level. Based on the 
estimated risk level, the RHW application decides to deliver an HMI warning to user. 



C.5 Information-centric forwarding 

Information-centric forwarding is a potentially advanced functionality that can be provided by the facilities layer. 

Information-centric forwarding is based on ITS stations that relay a received DENM to other incoming ITS stations as 
long as the event information included in DENM is still valid. The forwarding decision is made at the ITS facilities 
layer. 

Information-centric forwarding requires an ITS station to physically keep the received DENMs at the ITS facilities 
layer during the event duration time and within the relevance area. Information-centric forwarding can be activated by 
the DEN management. Information-centric forwarding is illustrated in figure C.l by the dashed line. For such purpose, 
the DEN management provides the following functionalities: 



• 



Facilities layer forwarding decision: the DEN management at a receiver ITS station should make a decision 
whether the received DENM need to be further forwarded. 

• DENM suppression: the DEN management deletes the redundant and outdated DENMs and provides updated 
or reliable DENMs for forwarding. 

• Third party delaying: in case the originator ITS station looses the capacity to broadcast DENMs, it may request 
an authorized third party ITS station to relay the DENMs. This third party ITS station is an authorized ITS 
station. This third part ITS station is not necessarily located in the relevance area. 

NOTE: Information centric forwarding is different from the store-and-forward functionality as defined in the ITS 
networking and transport layer. 



C.6 HIVII warning 



This procedure requires HMI device to display appropriate HMI warnings to the driver or other road users based on the 
risk estimation for a received DENM. An HMI warning is required to be provided at a time that allows the driver to 
make manoeuvring for collision avoidance. 
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Annex D (informative): 

Text description of an example relevance area 

Table D.l provides an example of text description of the event reference position, the relevance area, and the 
destination area. 

Table D.l : Example relevance position, relevance area 
and destination area text description 



Event 


Reference Position 


Relevance area 


Destination area 


Emergency electronic 
brake lights 


Vehicle current position 


Certain distance within the 
upstream traffic of the vehicle 
position 


Rectangle covering road 
topology 


Wrong way driving 
warning 


Vehicle current position 


Road section of the wrong 
way driving and the linked 
road sections 


Circle covering all 
concerned road sections 


Stationary vehicle - 
accident 


Accident vehicle position 


Certain distance within the 
upstream traffic of the vehicle 
position 


Rectangle covering road 
topology 


Stationary vehicle - 
vehicle problem 


Stationary vehicle position 


Certain distance within the 
upstream traffic of the vehicle 
position 


Rectangle covering road 
topology 


Traffic condition warning 


Position of the 
downstream end of the 
traffic jam 


Certain distance within the 
upstream traffic of the 
upstream end of the traffic 
jam 


Rectangle covering road 
topology 


Signal violation warning 


Position of vehicle 
violating the signal 


Intersection road sections 


Ellipse covering the 
intersection area 


Roadwork warning 


Downstream end position 
of the road work zone 


Certain distance within the 
upstream traffic of the 
upstream end position of the 
roadwork section 


Rectangle covering road 
topology 


Collision risk warning 


Estimated collision 
position 


Intersection area 


Ellipse covering the 
intersection area 


Hazardous location 


Downstream end position 
of the hazardous location 


Certain distance from the 
hazardous location position 


Circle covering road 
sections towards hazard 
location 


Precipitations 


Downstream end position 
of the precipitation 


Certain distance from the 
precipitations area 


Circle covering road 
sections towards hazard 
location 


Road adhesion 


Downstream end position 
of the low road adhesion 
area 


Certain distance from the low 
adhesion area 


Circle covering road 
sections towards hazard 
location 


Visibility 


Downstream end position 
of the low visibility area 


Certain distance from the low 
adhesion area 


Circle covering road 
sections towards hazard 
location 


Wind 


Downstream end position 
of the strong wind area 


Certain distance from the 
strong wind area 


Circle covering road 
sections towards hazard 
location 
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